1. Field of the Invention
The present invention relates to an apparatus and method for handover between heterogeneous networks. More particularly, the present invention relates to an apparatus and method that provide enhanced heterogeneous network handover using a media independent handover scheme.
2. Description of the Related Art
Handover, or handoff, is a technical procedure for switching a call in progress from the radio coverage area of one base station to another base station while ensuring the continuity of the established call.
Handover is commonly performed when user equipment, currently in an active communication session, moves between the cells of a homogenous system. With the deployment of various heterogeneous system networks, advanced handover techniques for supporting handover between heterogeneous networks have been developed. Handover between heterogeneous networks (also known as vertical handover) means an inter-technology handover such as a switch between a WiBro network and another standard system network, such as a 2nd generation (2G) network, a 3rd generation (3G) network, or a wireless local area network (WLAN) based on the Institute of Electrical and Electronics Engineers 802.11 (IEEE 802.11) standards.
Media Independent Handover (MIH) is a standard being developed as part of the IEEE 802.21 standard to enable handover in a heterogeneous network environment. MIH is a seamless intermediate handover technique guaranteeing quality of service (QoS) between heterogeneous networks regardless of media types. MIH provides Event Services, Command Services and Information Services for allowing a mobile node having multiple radio interfaces to switch the communication session in progress to an optimal network regardless of media type without requiring user interface. With such services, the upper layers can perform a handover to an optimal network.
FIG. 1 illustrates message flows in a conventional inter-system handover procedure. In FIG. 1, a mobile node (MN) 100 is attempting a handover from a WLAN to a wireless metropolitan area network (WMAN).
Referring to FIG. 1, a mobile node (MN) 100 is serviced by a WLAN 101 as a serving network in step S110. If a link status changes, the MN 100 transmits an MIH get information request message (MIH_Get_Information.request) to neighbor networks via an MIH Information Service (MIIS) server 102 in step S115. The change of link status is determined by comparing a link parameter value with a threshold value. If the link parameter value is greater than the threshold value, it is determined that a change of link status has occurred. The high link parameter value indicates that the received signal strength is weak. Accordingly, the MN 100 determines information about neighboring networks, such as received signal strengths of the different networks, and prepares to perform a handover to the neighboring network having an optimal state. The MIH_Get_Information.request message is formatted as follows and the parameters of the MIH_Get_Information.request message are defined as in table 1.
MIH_Get_Information.request (             InfoQueryType,             InfoQueryParameters             )
TABLE 1ValidNameTypeRangeDescriptionInfoQueryTypeAn integer value correspondingN/AThe type of query that is specifiedto one of the followingtypes:1: TLV2: RDF_DATA3: RDF_SCHEMA_URL4: RDF_SCHEMAInfoQueryParametersQuery type specific parametersN/AQuery type specific parameters which indicatethe type of information the client may beinterested in.
The MIH_Get_Information.request is transmitted by MN 100 to request information related to a specific interface, attributes to the network interface as well as entire network capability.
As shown in table 1, integer values of the InfoQueryType parameter of the MIH_Get_Information.request respectively correspond to TLV, RDF_DATA, RDF_SCHEMA_URL, and RDF_SCHEMA.
When the InfoQueryType is specified as TLV, the InfoQueryParameters is a binary string. When the InfoQueryType is specified as RDF_DATA, the InfoQueryParameters is a string which contains a SPARQL (Protocol and RDF Query language) query where the SPARQL query is supposed to contain an appropriate query for obtaining expected RDF/XML data. When the InfoQueryType is specified as RDF_SCHEMA_URL, the InfoQueryParameters is a null string. Finally, when InfoQueryType is specified as RDF_SCHEMA, the InfoQueryParameters carries either the URL of the extended schema the query originator wants to obtain or a null string when the URL of the extended schema is unknown.
In response to the MIH_Get_Information.request message, the MIIS server 102 transmits an MIH get information response message (MIH_Get_Information.response) to the MN 100 in step S117. The MIH_Get_Information.response message includes information on the candidate networks that are selected by the MIIS server 102 in consideration of the location of the MN 100. Upon receiving the MIH_Get_Information.response message, the MN 100 determines link relief information in step S120. That is, the link layer of the MN 100 notifies that the current link established by MIH is released within a predetermined time. Accordingly, the MN 100 determines another link to perform handover to a new cell, i.e. a new network.
Next, the MN 100 receives information required for a new connection from WMANs 103 and 104 as the candidate networks in steps S125 and S126. For simplifying the explanation, it is assumed that two WiBro networks based on the IEEE 802.16 standard are selected as the candidate networks in FIG. 1. However, the number of the candidate networks can be changed and other the types of networks, such as cellular networks and WLANs, can be utilized.
Since the candidate networks 103 and 104 are WiBro networks, the connection information includes Downlink MAP (DL MAP), Uplink MAP (UL MAP), Downlink Channel Descript (DCD), and Uplink Channel Descript (UCD).
If the network connection information is collected, the MN 100 performs a link scanning on the links of the candidate networks 103 and 104 in step S130 and then transmits a candidate query request message (Candidate_Query. request) including the information on the candidate networks 103 and 104 to the serving network 101 in step S132. The Candidate_Query.request includes a link type identifier, network identifiers of the candidate networks, and information about operations required for the current link after handover. Upon receiving the Candidate_Query.request message, the serving network 101 transmits a handover (HO) query resource request message (Query_Resource.request) to the candidate networks 103 and 104 in steps S135 and S136. The candidate networks are selected in consideration of the location of the MN 100, and the number and types of candidate networks are not limited to the example of FIG. 1. In a case where five candidate networks are reported by the MIIS server 102, the serving network 101 requests the radio resource information for handover to the five candidate networks.
In response to the Query_Resource.request, the respective candidate networks 103 and 104 transmit a query resource response message (Query_Resource.response) containing information on their resources to the service network 101 in steps S137 and S138. Particularly, the handover resource information response message may include handover acceptability for the MN 100. The serving network 101 determines one of the candidate networks as an optimal network for handover in consideration of the handover acceptability and resource status of the candidate networks 103 and 104. Next, the serving network 101 transmits a Candidate_Query.response containing information on the HO target network to the MN 100 in step S140.
Assuming that the candidate network 103 is selected as the handover target network, the MN 100 performs operations for establishing a connection to the target network 103. Since the handover target network 103 is a WiBro network, the MN 100 performs a ranging process for establishing a connection link in step S145. After completing the ranging process, the MN 100 determines successful handover completion in step S147 and is served by the new serving network 103 in step S150. Here, the communication link to the old service network 101 is released. In this manner, the vertical handover between heterogeneous networks is performed.
As described above, in the vertical handover specified by the IEEE 802.21 standard, the MN transmits MIH_Get_Information.request to the MIIS server whenever a handover to a new cell is required, and the MIIS server collects information on the networks in a core network and determines the existence of available heterogeneous networks for handover. The MIIS server transmits the network status information to the MN using the MIH_Get_Information.response message.
In the conventional standard specification, when a handover is required due to the movement of the MN, the core network predicts a location of the MN using a prediction algorithm and informs the MN of whether a handover to a heterogeneous network is available. In the heterogeneous network environment, however, the network resource management for the vertical handover is very complicated and inefficient real time handover traffic may cause significant network problems. Such problems increase latency and deteriorate communication reliability. That is, the conventional vertical handover method is limited in efficient handover performance due to the latency and communication reliability caused by inaccurate user location and mobility estimated by the core network.